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(54) System and method to verify trusted status of peer in a peer-to-peer network environment 



(57) A system and method for verifying that a peer 
is a trusted peer using signed receipts in a peer-to-peer 
network environment are disclosed. The method gener- 
ally comprises broadcasting a request over the network 
by a requesting peer for a task with respect to a remote 
non-local backend server, receiving a response to the 
request from the service-providing server, verifying a 
digital certificate of the response issued by the remote 



non-local backend server indicating that the responding 
service-providing server is trusted for the requested 
task, and forwarding the task to a local alias URL of the 
responding peer for performance of the task by the re- 
sponding server if the verifying is successful. The digital 
certificate may be a 1 024-bit VeriSign digital certificate. 
The verifying ensures that the local alias URL is ap- 
proved by the non-local backend server for the request- 
ed task. 
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Description 

CROSS REFERENCE TO RELATED APPLICATIONS 

[0001 ] This application claims the priority benefit of U. 
S. Provisional Patent Application No. 60/282,333, enti- 
tled "System and Method for Efficient Use of Bandwidth 
and Resources in a Peer-to-Peer Network Environment" 
and filed April 6, 2001 and U.S. Provisional Patent Ap- 
plication No. 60/298,681 , entitled "System and Method 
for Efficient Updating of Virus Protection Software and 
Other Efficient Uses of Bandwidth and Resources in a 
Peer-to-Peer Network Environment" and filed June 15, 
2001 , both of which are incorporated herein by refer- 
ence in their entireties. 

BACKGROUND OF THE INVENTION 

1 . Field of the Invention 

[0002] The present invention relates generally to a 
system and method for securely confirming perform- 
ance of a task by a peer in a peer-to-peer network en- 
vironment. More specifically, a system and method for 
verifying that a peer is a trusted peer using signed re- 
ceipts in a peer-to-peer network environment are dis- 
closed. 

2. Description of Related Art 

[0003] Conventionally, to obtain anti-virus product up- 
dates and/or signature files, computers rely on a pull ap- 
proach in which each client or server computer must re- 
trieve the updated anti-virus file directly from a source 
via the Internet. For a computer network, a network ad- 
ministrator may allow anti-virus signature files to be- 
come out of date because there are simply too many 
clients on the network for effective management. Alter- 
natively, the network administrator may schedu le the cli- 
ents to automatically pull the updated anti-virus file from 
the Internet when each client logs onto the computer. 
However, such an approach can result in a bandwidth 
crunch such as in the early morning work hours when 
most users log onto their computers. 
[0004] Connections to the Internet from within an or- 
ganization, particularly from a small to medium sized or- 
ganization, may be relatively slow. For example, a small 
to medium sized business may share a single cable or 
DSL modem, a56K modem, oran ISDN line. In contrast, 
in a typical work group interconnected via a LAN, con- 
nections on the LAN are generally much faster, the typ- 
ical LAN being 100/TX (100 Mbps). Peer-to-peer net- 
works thus partially address the need for efficient use of 
bandwidth and resources in a computer network. 
[0005] In addition, some peers in a network may be 
restricted from accessing the Internet. Thus, various 
service providers on a peer-to-peer network may be re- 
quested to perform certain actions on behalf of other 



peers on the network, such as tasks that require access 
to the Internet. However, conventionally, any given peer 
on the network potentially may be able to specify that it 
is capable of performing the requested service while the 
5 requesting peer does not have a way to verify that the 
responding peer is trusted. 

[0006] Thus, it is desirable to provide a system and 
method for an efficient and effective way for a requesting 
peer to securely verify that a responding peer is trusted. 

10 

SUMMARY OF THE INVENTION 

[0007] A system and method for verifying that a peer 
is a trusted peer using signed receipts in a peer-to-peer 

*5 network environment are disclosed. The peering service 
system and method facilitate in spreading load amongst 
peers in a distributed network interconnected via a LAN 
in a smooth, secure and scalable way. The service pro- 
vider selection from among the peers is preferably 

20 achieved through an automatic selection process using 
signed certificates to authenticate the legitimacy of each 
potential service provider. Upon completion of the se- 
lection process, the selected service provider optionally 
transmits a broadcast message over the network to no- 

25 tify all other peers of the outcome of the selection proc- 
ess. 

[0008] It should be appreciated that the present inven- 
tion can be implemented in numerous ways, including 
as a process, an apparatus, a system, a device, a meth- 

30 od, or a computer readable medium such as a computer 
readable storage medium or a computer network where- 
in program instructions are sent over optical or electron- 
ic communication lines. Several inventive embodiments 
of the present invention are described below. 

35 [0009] According to a preferred embodiment, the 
method generally comprises broadcasting a request 
over the network by a requesting peer for a task with 
respect to a remote non-local backend server, receiving 
a response to the request from the service-providing 

40 server, verifying a digital certificate of the response is- 
sued by the remote non-local backend server indicating 
that the responding service-providing server is trusted 
for the requested task, and forwarding the task to a local 
alias URL of the responding peer for performance of the 

45 task by the responding server if the verifying is success- 
ful. The digital certificate may be a 1 024-bit VeriSign dig- 
ital certificate. The verifying ensures that the local alias 
URL is approved by the non-local backend server for 
the requested task. 

50 [0010] The method may further comprise placing the 
responding server node in a black list of the requesting 
peer for the requested task and/or awaiting for another 
response from another service-providing server if the 
verifying is unsuccessful. In addition, the method may 

55 include broadcasting a message indicating that the re- 
questing peer has located the responding service-pro- 
viding server. The request preferably specifies a post 
method and the local alias URL generally points to a 
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destination on a responding server node. The requested 
task is typically an uploading task such that forwarding 
of the task to the local alias URL includes forwarding a 
file to be uploaded to the remote non-local backend 
server. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0011] Preferred features of the present invention will 
now be described, by way of example only, with refer- 
ence to the accompanying drawings, in which like refer- 
ence numerals designate like structural elements, and 
in which: 

FIG. 1 is a block diagram of an exemplary computer 
network suitable for implementing a peering service 
in a peer-to-peer network to facilitate efficient use 
of bandwidth and resources; 

FIG. 2 is a block diagram illustrating an exemplary 
peering service system and method implemented 
at a node of the computer network of FIG. 1 ; 
FIG. 3 is a state diagram illustrating states of a typ- 
ical peering service server in processing a request 
from a peering client in the peer-to-peer network; 
FIGS. 4A and 4B are alternative state diagrams il- 
lustrating states of a typical peering service client 
in requesting a resource over the peer-to-peer net- 
work; 

FIG. 5 is a flowchart illustrating a typical process of 
a peering service server in processing a request 
from a peering client in the peer-to-peer network; 
FIG. 6 is a flowchart illustrating a typical process of 
a peering service client in requesting a resource 
over the peer-to-peer network; 
FIG. 7 is a flowchart illustrating a preferred embod- 
iment of the retrieve step of FIG. 6 in more detail; 
FIG. 8 is a block diagram illustrating a typical shared 
agent architecture with various peering service- 
aware applications and non-peering service aware 
applications; 

FIG. 9 is a flowchart illustrating an exemplary proc- 
ess implemented by a node for verifying that a re- 
sponding peer is a trusted peer using signed re- 
ceipts in a peer-to-peer network environment; 
FIG. 10 illustrates an example of a computer system 
that can be utilized with the various embodiments 
of method and processing described herein: and 
FIG. 11 illustrates a system block diagram of the 
computer system of FIG. 10. 

DESCRIPTION OF SPECIFIC EMBODIMENTS 

[0012] A system and method for verifying that a peer 
is a trusted peer using signed receipts in a peer-to-peer 
network environment are disclosed. The peering service 
facilitates in spreading load amongst peers in a distrib- 
uted network interconnected via a LAN in a smooth, se- 
cure and scalable way. A service or an application that 



is service-enabled may minimize or reduce the usage 
of, for example, Internet bandwidth by attempting to lo- 
cate a local aliased copy of a requested resource resid- 
ing within the peer-to-peer network. If a local aliased 

5 copy of the requested resource is located, the request- 
ing computer may obtain the requested resources local- 
ly. Once the requesting computer obtains a copy of the 
requested resource, whether locally or remotely, the re- 
questing computer may itself become a server for the 

10 aliased copy for subsequent requests for the resource. 
[0013] The following description is presented to ena- 
ble any person skilled in the art to make and use the 
invention. Descriptions of specific embodiments and ap- 
plications are provided only as examples and various 

is modifications will be readily apparent to those skilled in 
the art. The general principles defined herein may be 
applied to other embodiments and applications without 
departing from the spirit and scope of the invention. 
Thus, the present invention is to be accorded the widest 

20 scope encompassing numerous alternatives, modifica- 
tions and equivalents consistent with the principles and 
features disclosed herein. For purpose of clarity, details 
relating to technical material that is known in the tech- 
nical fields related to the invention have not been de- 

25 scribed in detail so as not to unnecessarily obscure the 
present invention. 

[0014] FIG. 1 is a block diagram of an exemplary com- 
puter network 1 00 suitable for implementing the peering 
service in a peer-to-peer network to facilitate efficient 

30 use of bandwidth and resources as described herein. In 
particular, the computer network 1 00 comprises nodes, 
computers, or workstations 104A-E interconnected via 
a LAN 1 02. It is to be understood that the LAN 1 02 may 
be implemented using any suitable network mechanism 

35 including wire and wireless. In the exemplary computer 
network 1 00, only two of the nodes 1 04D and 1 04E have 
access to the Internet. 

[0015] FIG. 2 is a block diagram illustrating an exem- 
plary peering service system and method implemented 

40 at a node of the computer network of FIG. 1 . As shown, 
each node 1 04 provides the functionality of both a server 
1 06 and a client 1 1 0. The peering service system utilizes 
a port, such as port 1967, for transmitting directed or 
broadcast messages to peers on the network. The serv- 

45 er preferably includes an embedded HTTP server 1 08, 
typically a micro HTTP server. The HTTP server 1 08 al- 
lows aliased URLs to be accessed by other peers on the 
network. The HTTP server 108 preferably uses an ob- 
scure port such as port 651 5 and is preferably restricted 

50 to operations required to facilitate distribution of, for ex- 
ample, cached files and uploading of data or requests. 
[0016] Typically, each node runs both the server and 
the client. However, each node may run only the client 
or the server. The peering system and method are pref- 

55 erably implemented as a peering service application 
("service" or "service-enabled application") or daemon 
process. It is noted that a service-enabled application 
need not be a service application. For example, a serv- 
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ice-enabled application may also refer to a service- 
aware application that fires up, communicates with the 
service and then shuts down interactively. 
[0017] The peering system preferably provides a link- 
able client API library 112 to facilitate communication 
between the peering service and any service-enabled 
applications. In one preferred embodiment, the peering 
system may export the client API library 1 1 2 to any serv- 
ice-enabled application such that the service-enabled 
application may utilize the peering service to discover 
any type of resource that can be identified with a URL 
or URI, for example. Alternatively, a given application 
and the peering service may be tightly coupled so as to 
eliminate the need for the linkable client API library. 
[0018] FIG. 3 is a state diagram illustrating states 1 20 
of atypical peering service server in processing a given 
request from a peering client in the peer-to-peer net- 
work. Initially, the service server is in an idle state 122 
while listening on a designated port for a broadcast re- 
quest message from a peer client on the network. When 
the service server receives a broadcast request mes- 
sage such as an "I need" packet from a peering client 
on the network, the service server transitions to a locat- 
ing local aliased copy state 1 24. In particular, the service 
server refers to its list of local aliased copies to deter- 
mine if the service server has a local copy of the request- 
ed resource or item identified by, for example, an URL7 
URI. If the service server determines that it does not 
have a local copy of the requested resource, then the 
service server returns to the server idle state 122. 
[0019] Alternatively, if the service server determines 
that it has a local copy, the service server preferably 
waits a randomly generated delay response time period 
at stage 126. The service server may generate a ran- 
dom number such as between 0 and 2000, which the 
service server utilizes as the length of time it waits be- 
fore responding. In one preferred embodiment, the ran- 
dom number is the number of milliseconds the service 
server waits before replying to the request. While the 
service server awaits expiry of the randomly generated 
delay response time period, the service server listens 
for a broadcast "I found" packet from the requesting cli- 
ent corresponding to the received request packet. It is 
noted that regardless of the state of the service server 
for a given peer request, the service server listens for 
new requests such as "I need" packets. The broadcast 
"I found" packet from the requesting client indicates that 
the requesting client has found the requested resource. 
If the service server receives an "I found" packet from 
the requesting client before expiry of the delay response 
time period, the service server transitions to state 1 28 
to cancel the response to the request and returns to 
server idle state 122. 

[0020] Alternatively, if no "I found" packet is received 
prior to the expiration of the delay response time period, 
the service server transitions to state 1 30 to transmit an 
"I have" packet directly to the requesting peer client. The 
"I have" packet preferably contains a local alias for the 



requested object on the service server which the re- 
questing peer can access via the HTTP server of the of 
the service server Although not preferred, the service 
server may alternatively broadcast the "I have" packet 
5 over the network rather than transmitting it directly to 
the requesting client. The service server then returns to 
the server idle state 122. 

[0021] As is evident, the randomly generated delay 
response time period allows multiple peer servers to 

io share loads in an orderly fashion. In particular, rand- 
omizing the delay response time period ensures that 
any given node would not automatically become the de- 
fault serverto a large portion of the peers and eliminates 
any need for the service server to exercise preferences 

>5 as to which service clients the service server will supply 
the requested item. In other words, the random wait time 
before responding to a request ensures that any one 
machine does not become an overloaded server of the 
item or update to the rest of the network. In addition, as 

20 a given item is propagated through the network to peers 
on the network, the load on any one node is likely further 
reduced. Thus, the system impact on a given service 
server as it supplies the requested item to service clients 
can be relatively minimal. 

25 [0022] However, it is to be understood that a situation 
in which multiple service servers each transmitting an "I 
have" packet in response to a given request packet may 
occur. For example, a first service server may transmit 
an "I have" packet upon expiry of its delay response time 

30 period. The "I found" packet transmitted or to be trans- 
mitted by the requesting peer corresponding to the first 
"I have" packet may not arrive at the second service 
server prior to the expiry of its delay response time pe- 
riod, causing the second service server to transmit an "I 

35 have" upon expiry of its delay response time period. In 
such a situation where the requesting client receives 
multiple "I have" packets from multiple service servers, 
the requesting client may simply process the first "I 
have" response and ignore any subsequent "I have" 

40 packets it may receive. 

[0023] FIGS. 4A and 4B are alternative state dia- 
grams illustrating states 140, 140A of a typical peering 
service client in making a given request for a resource 
over the peer-to-peer network. Referring to FIG. 4A, in- 

^5 itially, the service client is in an idle state 142. When a 
service client needs a desired resource, such as an In- 
ternet resource, the service client generates and broad- 
casts an "I need" packet over the peer-to-peer network. 
For example, the "I need" request may specify an URL 

50 (e.g., 

http://something.tld/someother/thing/here). a protocol 
(e.g., HTTP protocol), a desired operation (e.g., get op- 
eration), and that the requesting peer only wants cached 
objects. 

55 [0024] After broadcasting the "I need" request, the 
service client transitions to a waiting for response state 
1 44 in which the service client awaits a maximum delay 
response time period plus atransmission time periodfor 
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a response from any of the service servers. In the ex- 
ample above where the randomly generated delay re- 
sponse time period ranges between 0 and 2000 milli- 
seconds, the client response waiting time period would 
be, for example, 2200 milliseconds to allow for a 200 
millisecond transmission time period. 
[0025] If an "I have" response is received from a serv- 
ice server during the client response waiting time, then 
the service client transitions to state 146 and generates 
and broadcasts an "I found" message over the network 
to inform all other peers that the desired resource or item 
has been found. The service client then transitions to 
the requested item found state 158. The service-ena- 
bled application requesting the item then retrieves the 
requested item from the responding service server at 
the location within the network as specified in the re- 
ceived "I have" packet. Generally, the service-enabled 
application retrieves the requested item through the lo- 
cal HTTP server using, for example, port 6515. Once 
the service-enabled application successfully retrieves 
the requested item, the service client informs the service 
server running on the same machine that a local copy 
of the resource now exists. The service client then re- 
turns to the idle state 142. 

[0026] Alternatively, if no response is received during 
the client response waiting time, the service client times 
out and transitions to state 1 50 to retrieve the requested 
item itself such as via the Internet. Once the retrieval is 
complete, the service client transitions to found item 
state 1 58 in which the service client informs the service 
server running on the same computer or at the same 
node that a local copy of the resource now exists. The 
service client then returns to client idle state 142. As is 
evident, regardless of whether the service client re- 
ceived an "I have" packet from a service server on the 
network, the client machine can itself become a service 
server for the requested resource after successful com- 
pletion of its request. 

[0027] FIG. 4B illustrates the 1 40A states of a typical 
service in a preferred alternative embodiment particu- 
larly suitable for applications that include downloading 
of files. States 140A includes the states as shown and 
described with reference to FIG. 4A plus additional 
states for dealing with currently in-progress downloads 
of the requested item by other peers. These additional 
states allow a peer node to complete downloading the 
requested resource and then distribute it immediately 
and automatically upon download completion to the re- 
questing service client. 

[0028] In particular, instead of directly transitioning to 
state 150 to retrieve the requested item itself after the 
service client times out the request, the service client 
transitions to "waitfor download?" state 1 44 in which the 
service client determines whether it can or will wait for 
completion of any in-progress download of the request- 
ed item by another peer. If not, then the service client 
transitions to state 150 to retrieve the requested item 
itself and continues with state transitions similar to that 



described above with reference to FIG. 4A. 
[0029] If the service client determines that it can or 
will waitforthe completion of any in-progress download, 
the service client transitions to "any in-progress down- 

5 loads?" state 152. If there are no such in-progress 
downloads of the requested item, then the service client 
transitions to state 150 to retrieve the requested item 
itself and continues with state transitions similar to that 
described above with reference to FIG. 4A. 

10 [0030] Alternatively, if there is at least one in-progress 
download of the requested item, then the service client 
transitions to state 154 in which it generates and broad- 
casts an "I found" message. The service client then tran- 
sitions to state 156 to await completion of the in- 

15 progress download of the requested item. Upon com- 
pletion of the in-progress download of the requested 
item, the service client transitions to the requested item 
found state 158. The service client retrieves the request- 
ed item from the local location within the network. After 

20 successful completion of its request, the service client 
will inform the service server running on the same ma- 
chine that a local copy of the resource now exists. The 
service client then returns to the idle state 1 42. 
[0031] As is evident, in order for the service client to 

25 determine if there are any in-progress downloads in 
state 152, a service client that is downloading a file for 
a service-enabled application preferably broadcasts a 
"downloading" message and/or directly responds to the 
client server of a broadcast "I need" request with a "I am 

30 downloading" rather than an "I have" response mes- 
sage. In one preferred embodiment, the service client 
may set a downloading flag for the corresponding file to 
true. 

[0032] In addition, the service-enabled application 
35 preferably transmits periodic progress packets to any 
node that is waiting for the resource being downloaded 
such that those nodes may interactively display down- 
load progress information to end users at state 156. Al- 
ternatively, the service-enabled application may broad- 
40 cast such periodic download progress packets over the 
network. Thus, a node in the retrieve item state 1 50 pref- 
erably periodically transmits a "downloading" message 
that includes progress information. 

45 Service Functionality and Service Packet Format 

[0033] One functionality provided by the peering serv- 
ice is that of a central clearing house for formatting, 
sending, receiving and decoding service packets, such 

50 as for "I need," "I found," and "I have" packets. In other 
words, the peering service manages the peer-to-peer 
communication process for obtaining requested items. 
The specific functionality invoked by a given service 
packet itself is generally dependent on the specific serv- 

55 ice-enabled application. 

[0034] The communication protocol used in broad- 
casts (e.g., "I need" and "I found" packets) and respons- 
es (e.g., "I have" packets) is typically TCP/IP. Each 
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packet is typically approximately 200 bytes in size and 
contains the node ID of the sender as well as any other 
suitable information. Transfer of the requested item from 
the service server to the service client is typically via 
HTTP. 5 
[0035] The service packet format is preferably based 
upon the well-accepted and widely utilized XML format. 
For example, an XML service packet format may include 
a service identification and various key-value pairs, in- 
cluding those inserted by the service as well as those 
defined by the corresponding service-enabled applica- 
tion. 

[0036] Various key-value pairs may be inserted by the 
peering service into each service packet. Examples of 
suitable key-value pairs include identification, type, and 
version key-value pairs. Specifically, an identification 
key-value pair identifies each request and responses 
corresponding to the request. In general, the identifica- 
tion value is unique on the originating node but need not 
be unique on the network as a whole. The range of val- 
ues for the identification value may depend upon the 
number of bits assigned thereto. For example, 32 bits 
or four octets may be assigned to the identification value 
and thus the identification value would range from 0 to 
2 31 . With respect to the type key- value pair, the type val- 
ue is typically either request, end-request, response, 
and/or any application-defined value. Any other suitable 
application-defined key-value pairs may also be in- 
cludes in the service packet. 
[0037] An exemplary service packet may be: 

<service type = "request" version = "1 .0" ID = 
"1111" method = "get" 

href = "http:/d omain.com/whatever" acceptproto- 
col - "http"/> 

[0038] FIG. 5 is a flowchart illustrating a typical proc- 
ess 180 of a peering service server in processing a re- 
quest from a peering client in the peer-to-peer network. 
At step 182, the service server is listening on a desig- 
nated port for a broadcast request message from a peer 
client on the network. At step 184, the service server 
receives a broadcast request message on the designat- 
ed port such as an "I need" packet from a peering client 
on the network. At step 186, the service server deter- 
mines if it has a local aliased copy of the requested item. 
In particular, the service server refers to its list of local 
aliased copies to determine if the service server has a 
local version of the requested resource or item, such as 
an URLAJRl. 

[0039] If the service server determines that it does not 
have a local copy of the requested resource, then the 
process 180 is complete. Alternatively, if the service 
server determines that it has a local copy, the service 
server preferably waits a randomly generated delay re- 
sponse time period while listening for a broadcast "I 
found" packet from the requesting client corresponding 
to the received request packet at step 1 88. As discussed 
above, the service server may generate a random 
number between 0 and 2000 as the length of time in 



milliseconds it waits before responding. The broadcast 
"I found" packet from the requesting client indicates that 
the requesting client has found the requested resource. 
[0040] It is noted that throughout the process 180 ; the 
service server is preferably continuously listening for 
any additional broadcast request messages and per- 
forms process 1 80 for each received broadcast request 
message as they are received. 

[0041] If the service server receives an "I found" pack- 
et from the requesting client before expiry of the delay 
response time period, the service server cancels the re- 
sponse to the request at step 1 90 and the process 1 80 
is complete. Alternatively, if no "I found" packet is re- 
ceived prior to the expiration of the delay response time 
period, the service server transmits an "I have" packet 
directly to the requesting peer client at step 1 92 and the 
server process 180 is complete. The "I have" packet 
preferably contains a local alias for the requested object 
on the service server. 

[0042] FIG. 6 is a flowchart illustrating a typical proc- 
ess 200 of a peering service client in requesting a re- 
source over the peer-to-peer network. At step 202, the 
service client generates and broadcasts an "I need" 
packet over the peer-to-peer network on a designated 
port. At step 204, the service awaits for a response from 
any of the service servers on the network for a period 
equal to a client response waiting time period, typically 
a maximum delay response time period plus a transmis- 
sion time period, . 

[0043] If an "I have" response is received from a serv- 
ice server during the client response waiting time, then 
the service client generates and broadcasts an "I found" 
message over the network at step 206. The service-en- 
abled application requesting the item then retrieves the 
requested item from the responding service server at 
the location within the network as specified in the re- 
ceived "I have" packet at step 208. Once the service- 
enabled application successfully retrieves the request- 
ed item, the service client informs the service server run- 
ning on the same machine that a local copy of the re- 
source now exists at step 21 0. The process 200 is then 
complete. 

[0044] Alternatively, if no response is received during 
the client response waiting time, i.e., the service client 
times out, the service client determines if the service- 
enabled application can or will wait for completion of any 
in-progress download of the requested item by another 
peer at step 214. If not, the service client retrieves the 
requested item itself such as via the Internet at step 21 6 
and then proceeds to step 21 0 to complete the process 
200. 

[0045] If the service client determines that it can or 
will wait for the completion of any in-progress download, 
the service client determines whether there are any in- 
progress downloads at step 220. If there are no such in- 
progress downloads of the requested item, the service 
client then proceeds to step 21 0 to complete the process 
200. 
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[0046] If there is at least one in-progress download of 
the requested item, then the service client generates 
and broadcasts an "I found" message at step 222. The 
service client then awaits completion of the in-progress 
download of the requested item at step 224. For exam- 
ple, the service client may receive an "I have" or a 
"Download complete" message from the downloading 
peer. 

[0047] Upon completion of the in-progress download 
of the requested item, the service client retrieves the re- 
quested item from the local location within the network 
at step 226. After successful completion of its request, 
the service client then proceeds to step 21 0 to complete 
the process 200. It is noted that steps 21 4 and 220-226 
can be optional and preferably implemented for appli- 
cations that include downloading of files 
[0048] As is evident, in order for the service client to 
determine if there are any in-progress downloads at step 
220, a service client that is downloading a file for a serv- 
ice-enabled application from outside of the network, e. 
g., from the Internet, notifies its peers on the network 
that a downloading process is in progress . For example, 
FIG. 7 is a flowchart illustrating a preferred embodiment 
of the retrieve step 21 6 in more detail. 
[0049] As shown, the service client begins retrieving 
the requested item at step 21 6A. At step 21 6B, the serv- 
ice client may broadcast a "downloading" message and/ 
or directly respond with a "I am downloading" response 
message to any client server that transmitted a broad- 
cast "I need" request. In addition, the service client pref- 
erably also periodically transmits progress packets at 
step 21 6C either by broadcast or by direct transmission 
to any node that is waiting for the resource such that 
those nodes may interactively display download 
progress information to end users at those nodes. Alter- 
natively, steps 21 6B and 21 6C may be combined into a 
single periodic packet transmission in which each pack- 
et is a "downloading" message that includes progress 
information. 

Service-Enabled Product Updating Application 

[0050] One exemplary implementation of the peering 
service described herein is a product updating service 
implementation and a service-enabled application hav- 
ing a shared agent. The agent is shared by an anti-virus 
application and a firewall application. The peering serv- 
ice is encapsulated in a single DLL that contains com- 
ponents for performing an update service, namely, a 
peering server having an HTTP server, a peering client, 
and a product updating service. 

[0051] The product updating service determines what 
updates, if any, to request. If the product updating serv- 
ice determines that an update is necessary, the service 
client broadcasts an "I need" packet to request a specific 
URL for the necessary product updates. In other words, 
the peering service provides a mechanism for keeping 
service-enabled application, its engine, and its virus sig- 



nature files up-to-date. 

[0052] In particular, when a first computer or node 
boots, its product updater broadcasts an "I need" packet 
requesti ng for my update.cab file at a specified URL. The 

5 myupdate.cab file, e.g. , approximately 7-8k in size, con- 
tains a script with instructions on how to check the cur- 
rent version of the product, engine, and virus signature 
files against the latest available version so that the prod- 
uct updater can determine if an update is necessary. 

io This file may not be cacheable, so the service servers 
may not be able to offer it and can instead be obtained 
directly via the Internet. 

[0053] If the product updating service determines, 
based on the myupdate.cab file, that an update is nec- 

*5 essary, the product updating service, via the peering 
service, broadcasts an "I need" packet over the network. 
An update may include engine, DAT, and/or product up- 
dates. For any update files that are downloaded, wheth- 
er directly from the Internet and/or from one or more of 

20 the peers on the network, the product updating service 
preferably checks to ensure that the updates have been 
digitally signed. Once the updates are authenticated, 
they are installed at the requesting node. 
[0054] The product update service checks for updates 

25 at any suitable pre-defined intervals and/or upon occur- 
rence of various events. For example, the product up- 
date service may check for updates upon boot or 5 min- 
utes after boot, 6 hours after each unsuccessful check, 
and/or upon a scheduled basis such as once a day, once 

30 every 12 hours after each successful check. 

[0055] An update can include virus signature files 
(DATs), engine, and/or product update. DATs are typi- 
cally updated weekly, such on a particular day of the 
week and are approximately 900-950k in size on aver- 
ts age. The engine is usually updated every 2 to 3 months 
and is approximately 550-600k in size on average. The 
product is updated as hotfixes become available, typi- 
cally every 6-8 weeks, or as new versions become avail- 
able, typically every 4-6 months, and is approximately 

40 700-750k in size on average. 

[0056] In the current example, a complete update, in- 
cluding engine, virus signature files and product, com- 
prises of six *.cab files, totaling approximately 2.25M. 
The six *.cab files for an update and their respective av- 

45 erage sizes are listed below: 



55 [0057] As any number of these *.cab files may need 
to be updated, each file is preferably requested via the 
peering service in a separate transaction. Thus, some 
or all of the needed*. cab file may be pulled from different 



M y a vd at . Y Y M M D D H H M M . c a b 
Myxtrdat. YYM M DD HH M M .cab 
Mycioagt. Y Y M M D DH H M M . cab 
Vsasap . YYM M D D H H M M . cab 
Vseng9x.YYMMDDHHMM.cab 
Vsengine.YYMMDDHHMM.cab 



average 910k 
average 1 6k 
average 370k 
average 360k 
average 240k 
average 340k 
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nodes and/or the Internet. 

[0058] The peering service described herein is not 
limited to an updating service but may be implemented 
with various other peering service-aware applications. 
FIG. 8 is a block diagram illustrating a typical shared 5 
agent architecture 500 with various peering service- 
aware applications and non-peering service aware ap- 
plications in which dashed lines represent process 
boundaries. As shown, an agent service manager 502 
manages the peering service 504, various peering serv- 
ice-aware applications such as upload, relay, and up- 
date services, 506, 508, 510, respectively, as well as 
other non-peering service aware applications such as 
HTTP server 512 and other such subsystems 514. As 
shown a client DLL serves as an interface between the 
peering service 504 and peering-aware services. In par- 
ticular, a client DLL 51 6 serves as an interface between 
the peering service 504 and peering-aware upload, re- 
lay, and update services, 506, 508, 510, respectively. In 
addition, a client DLL 518 serves as an interface be- 
tween the peering service 504 and an interactive user 
application 520. 

Service Performed by a Peer on Behalf of Another 
Peer in a Peer- to- Peer Environment 

[0059] An upload service is an example of a service 
that may need to be performed by a peer behalf of an- 
other peer such as where some peers are restricted 
from accessing the Internet (as shown in FIG. 1). For 
example, typical anti-virus applications require that the 
software application periodically contact the vendor 
server and report its current version and/or any applica- 
tion-specific data, i.e., uploading of files. In the case of 
anti-virus applications, the uploading of files typically in- 
cludes reporting viruses caught and the current DAT 
version. 

[0060] The upload subsystem (as shown in FIG. 8) is 
responsible for sending files such as reports from the 
client node to the vendor's backend servers. These re- 
ports are often XML files formatted in a way understood 
by the backend parser. To send the report, a properly 
formatted XML file is placed in the upload directory of 
the upload subsystem and the upload subsystem sends 
the file to the application vendor server via the Internet. 
If a given node is restricted from accessing the Internet, 
the node may perform upload task via a Internet-con- 
nected peer on the network if the upload subsystem is 
peering-system enabled. 

[0061] As is evident, service-enabling the upload ap- 
plication allows the upload subsystem at a non-connect- 
ed node to locate and perform tasks requiring Internet 
access via an upload subsystem at an Internet-connect- 
ed node. In particular, an Internet-connected peer node 
running the upload subsystem could respond to the re- 
questing node with an accessible alias for a post oper- 
ation. To reduce unnecessary network traffic, it may be 
desirable to require an upload subsystem at each node 



to optionally attempt a direct upload by default before 
broadcasting an upload request through the peering 
service. 

[0062] The peering-enabled upload subsystem pro- 
vides local aliases for "POST" operations similar to 
"GET" operations as described above. When an appli- 
cation residing at a non-connected node needs to per- 
form a "POST" operation, the application performs an 
alias lookup via the peering service. To perform the alias 
lookup, the peering service broadcasts an "I need" pack- 
et that preferably includes method = POST and URL set 
to the upload URL. The upload subsystem on an-lnter- 
net connected peer may reply to this request with a local 
alias that points to a vendor HTTP service server resid- 
ing at the connected node. Typically, this vendor HTTP 
server already uploads any files in its local upload direc- 
tory. The HTTP post operation simply places the file into 
the local upload directory as a uniquely named XML file. 
The existing upload functionality on the connected peer 
then uploads the file to the vendor backend server via 
the Internet. 

[0063] However, such a process poses new security 
risks. For example, it may be possible for a malicious 
machine on the LAN to spoof service clients into believ- 
ing it will upload for the requesting peer and then throw 
away, corrupt and/or misdirect the reports. Thus, in ad- 
dition to using the peering service for upload services, 
the peering service preferably implements a method for 
securely confirming performance of a task by a peer. 
[0064] FIG. 9 is a flowchart illustrating a exemplary 
process 580 implemented by a node for verifying that a 
responding peer is a trusted peer using signed receipts 
in a peer-to-peer network environment. FIG. 9 illustrates 
the process from a point of view of a non-connected 
service requesting peer. 

[0065] At step 582, the service requesting peer gen- 
erates and broadcasts an "I need" packet over the net- 
work. The "I need" packet preferably specifies method 
= POST and URL set to the upload URL. At step 584, 
the service requesting peer awaits an "I have" response 
communication from a service server on the network. 
[0066] When a response is received, the requesting 
peer determines whether the response contains a digital 
certificate issued by the vendor backend that indicates 
that the vendor backend has recently approved the ali- 
ased URL for the specified use, i.e., the requested task 
at step 586. Specifically, the response from the service 
server contains a local alias URL that points to a local 
upload directory for a vendor HTTP service server re- 
siding at the connected responding server node as well 
as a digital certificate. The digitally signed response may 
be signed by any suitable mechanism such as a 1 024-bit 
VeriSign digital certificate. In particular, the requesting 
peer requires that the responding upload server provide 
a digital certificate issued from the backend server that 
indicates that the responding server is trusted. The re- 
quired information may be contained in a single "I have" 
response communication or multiple communications. 
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The requesting peer may include a requestfor the digital 
certificate in its initial "I need" request packet. Alterna- 
tively, the requesting peer may respond to the "I have" 
packet from the responding server with a request for the 
digital certificate in a separate communication. 
[0067] If the digital certificate of the response commu- 
nication is not or cannot be verified at step 586, then the 
requesting peer may optionally place the responding 
server peer in a "black list" and report the responding 
server peer in a next report. The "black list" may be uti- 
lized by the requesting peer, for example, to prevent for- 
warding of any files to the servers listed in the "black 
list." The process then returns to step 584 to await a 
response from another service provider. Although not 
shown, steps to account for a situation where no satis- 
factory response is received by the requesting peer after 
a predetermine period of time may be implemented so 
as to end a process that cannot be successfully com- 
pleted. 

[0068] Alternatively, if the digital certificate of the re- 
sponse communication is verified at step 586, then the 
requesting peer preferably generates and broadcasts 
an "I found" message at step 590. At step 592, the re- 
questing peer forwards the file to be uploaded to the re- 
sponding service server at the alias URL specified in the 
response communication. The process at the request- 
ing peer is then complete. 

[0069] The responding service server generally has a 
peering service-enabled uploading service residing at 
the node. Typically, the vendor HTTP server at the re- 
sponding server node already performs the task of up- 
loading files from its local upload directory to the vendor 
backend server. The HTTP post operation simply places 
the file into the local upload directory as a uniquely 
named XML file. The existing upload functionality on the 
responding server machine then uploads the file to the 
vendor backend server via the Internet. 
[0070] Thus, the requesting peer requires verification 
that the responding service server is trusted to perform 
the requested task using signed certificates upon con- 
tact with the service provider. The verification is per- 
formed prior to the requesting peer accepting the serv- 
ice-supplied alias and prior to the requesting peer for- 
warding the data to be uploaded to the responding serv- 
ice server. 

[0071] As illustrated in the description above, the 
peering service facilitates in reducing or minimizing the 
number of service clients that have to obtain files or oth- 
er resources such as product update files via the Inter- 
net by using secure, peer-to-peercommunication to dis- 
tribute the files among client machines on a network, 
such as a LAN, via an intranet. The peering service en- 
ables secure, automatic distribution of the update files 
between service clients, independent of a network ad- 
ministrator or end-user, to keep the anti-virus and fire- 
wall application/service up-to-date with minimal impact 
to network bandwidth. 

[0072] Often, many computers on a network do not 



have the most up-to-date anti-virus and/or firewall files. 
Using the secure peering service allows for automatic 
and secure updating of such files and also reduces or 
eliminates the need for a network administrator to script 

5 anti-virus file updates. Furthermore, by efficiently 
spreading load and utilizing resources across a local 
network over a high-speed LAN , a bandwidth crunch re- 
sulting from the computers pulling update files from the 
Internet is largely reduced. Thus, the peering service al- 

10 lows for ease of distribution of product upgrades and up- 
dates with a minimal number of computers requiring to 
connect to the Internet to obtain the necessary files re- 
sulting in a reduced usage of Internet bandwidth. 
[0073] The peering service also allows a given client 

15 to pull the data files from any node on the network, rather 
than having to connect to a centralized server that might 
require several additional network hops, resulting in an 
optimal use of network bandwidth to distribute updates. 
[0074] FIGS. 10 and 11 illustrate a schematic and a 

20 block diagram, respectively, of an example of a general 
purpose computer system 1000 suitable for executing 
software programs that implement the methods and 
processes described herein. The architecture and con- 
figuration of the computer system 1 000 shown and de- 

25 scribed herein are merely illustrative and other compu- 
ter system architectures and configurations may also be 
utilized. 

[0075] The illustrative computer system 1000 in- 
cludes a display 1003, a screen 1005, a cabinet 1007, 

30 a keyboard 1 009, and a mouse 1011. The mouse 1011 
can have one or more buttons for interacting with a GUI 
(graphical user interface) that may be displayed on the 
screen 1005. The cabinet 1007 typically house one or 
more drives to read a computer readable storage medi- 

35 urn 1 01 5, system memory 1 053, and a hard drive 1 055, 
any combination of which can be utilized to store and/ 
or retrieve software programs incorporating computer 
codes that implement the methods and processes de- 
scribed herein and/or data for use with the software pro- 

40 grams, for example. Examples of computer or program 
code include machine code, as produced, for example, 
by a compiler or files containing higher level code that 
may be executed using an interpreter. 
[0076] Computer readable media may store program 

45 code for performing various computer-implemented op- 
erations and may be encompassed as computer stor- 
age products. Although a CD-ROM and a floppy disk 
1 01 5 are shown as exemplary computer readable stor- 
age media readable by a corresponding CD-ROM or 

50 floppy disk drive 1013, any other combination of com- 
puter readable storage media can be utilized. Computer 
readable medium typically refers to any data storage de- 
vice that can store data readable by a computer system. 
Examples of computer readable storage media include 

55 tape, flash memory, system memory, and hard drive 
may alternatively or additionally be utilized. Computer 
readable storage media may be categorized as magnet- 
ic media such as hard disks, floppy disks, and magnetic 
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tape; optical media such as CD-ROM disks; magneto- 
optical media such as floptical disks; and specially con- 
figured hardware devices such as application-specific 
integrated circuits (ASICs), programmable logic devices 
(PLDs), and ROM and RAM devices. Further, computer 
readable storage medium may also encompass data 
signals embodied in a carrier wave, such as the data 
signals embodied in a carrier wave carried in a network. 
Such a network may be an intranet within a corporate 
or other environment, the Internet, or any network of a 
plurality of coupled computers such that the computer 
readable code may be stored and executed in a distrib- 
uted fashion. 

[0077] Computer system 1000 comprises various 
subsystems. The subsystems of the computer system 
1000 may generally include a microprocessor 1051, 
system memory 1053, fixed storage 1055 (such as a 
hard drive), removable storage 1057 (such as a 
CD-ROM drive), display adapter 1059, sound card 
1061 , transducers 1063 (such as speakers and micro- 
phones), network interface 1065, and/or scanner inter- 
face 1067. 

[0078] The microprocessor subsystem 1051 is also 
referred to as a CPU (central processing unit). The CPU 
1 051 can be implemented by a single-chip processor or 
by multiple processors. The CPU 1 051 is a general pur- 
pose digital processor which controls the operation of 
the computer system 1000. Using instructions retrieved 
from memory, the CPU 1051 controls the reception and 
manipulation of input data as well as the output and dis- 
play of data on output devices. 

[0079] The network interface 1065 allows CPU 1051 
to be coupled to another computer, computer network, 
or telecommunications network using a network con- 
nection. The CPU 1051 may receive and/or send infor- 
mation via the network interface 1065. Such information 
may include data objects, program instructions, output 
information destined to another network. An interface 
card or similar device and appropriate software imple- 
mented by CPU 1 051 can be used to connect the com- 
puter system 1000 to an external network and transfer 
data according to standard protocols. In other words, 
methods and processes described herein may be exe- 
cuted solely upon CPU 1 051 and/or may be performed 
across a network such as the Internet, intranet net- 
works, or LANs (local area networks), in conjunction 
with a remote CPU that shares a portion of the process- 
ing. Additional mass storage devices (not shown) may 
also be connected to CPU 1051 via the network inter- 
face 1065. 

[0080] The subsystems described herein are merely 
illustrative of the subsystems of a typical computer sys- 
tem and any other suitable combination of subsystems 
may be implemented and utilized. For example, another 
computer system may also include a cache memory 
and/or additional processors 1051, such as in a multi- 
processor computer system. 

[0081] The computer system 1000 also includes a 



system bus 1069. However, the specific buses shown 
are merely illustrative of any interconnection scheme 
serving to link the various subsystems. For example, a 
local bus can be utilizedto connectthe central processor 

5 to the system memory and display adapter. 

[0082] While the present invention has been de- 
scribed in its preferred embodiments, it is to be under- 
stood that the words which have been used are words 
of description rather than limitation and that changes 

10 may be made to the invention without departing from its 
scope as defined by the appended claims. 
[0083] Each feature disclosed in this specification 
(which term includes the claims) and/or shown in the 
drawings may be incorporated in the invention inde- 

15 pendently of other disclosed and/or illustrated features. 

Claims 

20 1 . A method for verifying trusted status of a service- 
providing server in a peer-to-peer network, com- 
prising: 

broadcasting a request over the network by a 
25 requesting peer for a task with respect to a re- 

mote non-local backend server; 
receiving a response to the request from the 
service-providing server; 

verifying a digital certificate of the response is- 
30 sued by the remote non-local backend server 

indicating that the responding service-provid- 
ing server is trusted for the requested task; and 
forwarding the task to a local alias URL of the 
responding peer for performance of the task by 
35 the responding server if said verifying is suc- 

cessful. 

2. A method for verifying trusted status of a service- 
providing peer of claim 1 , wherein the digital certif- 

40 icate is a 1024-bit VeriSign digital certificate. 

3. A method for verifying trusted status of a service- 
providing peer of claim 1 , wherein said verifying ver- 
ifies that the local alias URL is approved by the non- 

45 local backend server for the requested task. 

4. A method for verifying trusted status of a service- 
providing peer of claim 1 , further comprising placing 
the responding server node in a black list of the re- 

50 questing peer for the requested task if said verifying 

is unsuccessful. 

5. A method for verifying trusted status of a service- 
providing peer of claim 1 , further comprising await- 

55 jpg for another response from another service-pro- 

viding server if the verifying is unsuccessful. 

6. A method for verifying trusted status of a service- 
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providing peer of claim 1 , further comprising broad- 
casting a message indicating that the requesting 
peer has located the responding service-providing 
server. 

7. A method for verifying trusted status of a service- 
providing peer of claim 1 , further comprising receiv- 
ing the local alias URL from the responding peer, 
the local alias URL pointing to a destination on a 
responding server node. 

8. A method for verifying trusted status of a service- 
providing peer of claim 1 , wherein the request spec- 
ifies a post method. 

9. A method for verifying trusted status of a service- 
providing peer of claim 1 , wherein the task is an up- 
loading task and wherein said forwarding the task 
to the local alias URL includes forwarding a file to 
be uploaded to the remote non-local backend serv- 
er. 

10. A computer program product for verifying trusted 
status of a service-providing peer in a peer-to-peer 
network, comprising: 

computer code that broadcasts a request over 
the network by a requesting peer for a task with 
respect to a remote non-local backend server; 
computer code that receives a response to the 
request from the service-providing server; 
computer code that verifies a digital certificate 
of the response issued by the remote non-local 
backend server indicating that the responding 
service-providing server is trusted for the re- 
quested task; and 

computer code that forwards the task to a local 
alias URL of the responding peer for perform- 
ance of the task by the responding server if said 
verifying is successful; and 
a computer readable medium that stores said 
computer codes. 



sponding server node in a black list of the request- 
ing peer for the requested task if said verifying is 
unsuccessful. 

5 14. A computer program product for verifying trusted 
status of a service-providing peer of claim 10, fur- 
ther comprising computer code that awaits for an- 
other response from another service-providing 
server if the verifying is unsuccessful. 

10 

15. A computer program product for verifying trusted 
status of a service-providing peer of claim 10, fur- 
ther comprising computer code that broadcasts a 
message indicating that the requesting peer has lo- 

15 cated the responding service-providing server. 

16. A computer program product for verifying trusted 
status of a service-providing peer of claim 10, fur- 
ther comprising computer code that receives the lo- 

20 cal alias URL from the responding peer, the local 

alias URL pointing to a destination on a responding 
server node. 

17. A computer program product for verifying trusted 
25 status of a service-providing peer of claim 10, 

wherein the request specifies a post method. 

18. A computer program product for verifying trusted 
status of a service-providing peer of claim 10, 

30 wherein the task is an uploading task and wherein 

computer code that forwards the task to the local 
alias URL includes computer code that forwards a 
file to be uploaded to the remote non-local backend 
server. 

35 



40 



11. A computer program product for verifying trusted 

status of a service-providing peer of claim 10, 45 
wherein the digital certificate is a 1 024-bit VeriSign 
digital certificate. 



12. A computer program product for verifying trusted 
status of a service-providing peer of claim 10, 50 
wherein the computer code that verifies includes 
computer code the verifies the local alias URL is ap- 
proved by the non-loca! backend server for the re- 
quested task. 

55 

13. A computer program product for verifying trusted 
status of a service-providing peer of claim 10, fur- 
ther comprising computer code that places the re- 



11 



EP 1 259 045 A2 






CLIENT 
110 












HTTP 
SERVER 
108 

SERVER 
106 






1 




LINKABLE 
CLIENT API 
LIBRARY 
112 





NODE 
104 



FIG. 2 



12 



EP 1 259 045 A2 



120 




FIG. 3 



13 



EP 1 259 045 A2 



140 




FIG. 4A 



14 



EP 1 259 045 A2 



140 A 




FIG. 4B 



15 



EP 1 259 045 A2 




START 



180 



LISTEN ON A DESIGNATED PORT OF A SERVICE SERVER FOR A BROADCAST 
REQUEST MESSAGE FROM A PEER CLIENT ON THE NETWORK 



'182 



V 



RECEIVE A BROADCAST REQUEST MESSAGE ON THE DESIGNATED PORT 
FROM A PEERING CLIENT ON THE NETWORK 



DOES^^-— 1 86 
SERVICE SERVER HAVEA~~ 
LOCAL ALIASED COPY OF THE 
REQUESTED 
ITEM? 

Yes 



AWAIT A RANDOMLY GENERATED DELAY RESPONSE PERIOD AND LISTEN 
FOR BROADCAST "I FOUND" PACKET FROM REQUESTING CLIENT 
CORRESPONDING TO RECEIVED REQUEST PACKET 



-188 



RECEPVE "I 
FOUND" PACKET 

\ 


190 

> 


192 
) 


EXPIRY OF DELAY 
RESPONSE PERIOD 


CANCEL RESPONSE TO REQUEST 




TRANSMIT "I HAVE" PACKET TO 
REQUESTING PEER CLIENT 




16 



EP 1 259 045 A2 



START 




200 



GENERATE AND BROADCAST "I NEED" PACKET OVER NETWORK 



^202 



AWAIT FOR A RESPONSE FROM ANY SERVICE SERVER ON THE NETWORK 
PERIOD EQUAL TO CLIENT RESPONSE WAITING TIME PERIOD 



-^204 



RECEIVE "I 
, r HAVE" PACKET 



.<=> 



206 



GENERATE AND BROADCAST "I 
FOUND" MESSAGE 



208 



RETRIEVE REQUESTED ITEM FROM 
RESPONDING SERVICE SERVER AT 
LOCATION SPECIFIED IN "I HAVE- 
PACKET 



210 



INFORM SERVICE SERVER ON SAME 
MACHINE THAT LOCAL COPY OF 
RESOURCE NOW EXISTS 



TIMEOUT 

WAIT "^«<214 
FOR COMPLETION OF 
.ANY IN-PROGRESS DOWN; 
LOADS? _ 

216 

No y 



Yes 



RETRIEVE REQUESTED ITEM, 
E.G., VIA INTERNET 




GENERATE AND BROADCAST 
"I FOUND" PACKET 



AWAIT COMPLETION OF IN- 
PROGRESS DOWNLOAD 



RETRIEVE ITEM FROM LOCAL 
LOCATION 



222 



224 



226 




FIG. 6 



17 



EP 1 259 045 A2 



216 




START 



BEGIN RETRIEVING REQUESTED ITEM 


^ 


r 


BROADCAST "DOWNLOADING" MESSAGE AND/OR DIRECTLY RESPOND 
WITH "DOWNLOADING" PACKET TO REQUESTING CLIENT SERVER OF 
BROADCAST "I NEED" REQUEST 


\ 


r 


PERIODICALLY TRANSMIT PROGRE! 
DIRECT TRANSMISSION TO ANY 


3S PACKETS BY BROADCAST OR BY 
NODE WAITING FOR RESOURCE 



'21 6A 



-216B 



-216C 




FIG. 7 



18 



EP 1 259 045 A2 



500 



AGENT SERVICE MANAGER 
502 



OTHER NON- 
PEERING 
SERVICE 
AWARE 

SUBSYSTEMS 
514 



PEERING 
SERVICE 
504 



CLIENT 
DLL 
516 



HTTP 
512 



INTERACTIVE 

USER 
APPLICATION 
520 



CLIENT 
DLL 
518 



UPLOAD 
506 



RELAY 
508 



UPDATE 
510 



FIG. 8 



19 



EP 1 259 045 A2 



START 



580 







GENERATE AND BROADCAST "I NEED" PACKET OVER NETWORK WITH 

METHOD = "POST" 


} 


f 


AWAIT RESPONSE FROM A SERVICE SERVER ON THE NETWORK 




RECEIVE RESPONSE 

f 



~~582 



-584 




PLACE RESPONDING 

SERVER PEER IN 
"BLACK LIST" AND 
REPORT IN NEXT 
REPORT 



GENERATE AND BROADCAST "I FOUND" MESSAGE 




r 


FORWARD UPLOAD FILE 
SPECIFIED IN "I 


TO PEER SERVER TO URL 
HAVE" PACKET 



'590 




-592 



FIG. 9 



20 



EP 1 259 045 A2 




1015 



1011 



1009 



1051 



PROCESSOR 



FIG. 10 



1053 



1001 



MEMORY 



1055 



FIXED 
STORAGE 



r 



1057 



REMOVABLE 
STORAGE 



-1069 
— *■ 



1059 



DISPLAY 
ADAPTER 



1009 



KEYBOARD 



.1003 



DISPLAY 



r 



1061 



SOUND 
CARD 



ion 



MOUSE 



1065 



NETWORK 
INTERFACE 



1 r 



1063 



SPEAKERS 



1067 



PRINTER/FAX/ 
SCANNER 
INTERFACE 



FIG. 11 



21 



(19) 



3 



Europaisches Patentamt 
European Patent Office 
Office europeen des brevets 



(12) 



(H) EP 1 259 045 A3 

EUROPEAN PATENT APPLICATION 



(88) 


Date of publication A3: 


(51) IntCI 7: H04L 29/06 




15.10.2003 Bulletin 2003/42 






(43) 


Date of publication A2: 








20.1 1 .2002 Bu lletin 2002/47 






(21) 


Application number: 02252465.6 






(22) 


Date of filing: 05.04.2002 






(84) 


Designated Contracting States: 


(72) 


Inventors: 




at rp r^ki r^v nc n w f=q ci cd /^r no ip it i i i it 

Al DC l^ri LrT UC LJ r\ Co rl rn laD Lj ri It I 1 L-l L.U 




Kouznetsov, Victor 




Mr Ml PX CP TO 




Aloha, OR 97007 (US) 




Designated Extension States: 


• 


Vigue, Charles L. 




AL LT LV MK RO SI 




Lapine, OR 97007 (US) 






• 


Fallenstedt, Martin 


(30) 


Priority: 06.04.2001 US 282333 




Beaverton, OR 97007 (US) 




15.06.2001 US 298681 


• 


Melchione, Daniel 




02.08.2001 US 922329 




Beaverton, OR 97739 (US) 


(71) 


Applicant: Networks Associates Technology, Inc. 


(74) 


Representative: Moir, Michael Christopher et al 




Santa Clara, CA 95054 (US) 




Mathys & Squire 








100 Gray's Inn Road 








London WC1X 8AL (GB) 



(54) System and method to verify trusted status of peer in a peer-to-peer network environment 



(57) A system and method for verifying that a peer 
is a trusted peer using signed receipts in a peer-to-peer 
network environment are disclosed. The method gener- 
ally comprises broadcasting a request over the network 
by a requesting peer for a task with respect to a remote 
non-local backend server, receiving a response to the 
request from the service-providing server, verifying a 
digital certificate of the response issued by the remote 
non-local backend server indicating that the responding 
service-providing server is trusted for the requested 
task, and forwarding the task to a local alias URL of the 
responding peer for performance of the task by the re- 
sponding server if the verifying is successful. The digital 
certificate may be a 1 024-bit VeriSign digital certificate. 
The verifying ensures that the local alias URL is ap- 
proved by the non-local backend server for the request- 
ed task. 



120 




CO 

< 

o 
o> 

LO 
CM 



Q_ 
LU 



FIG. 3 



Printed by Jouve, 75001 PAHIS (FR) 



EP 1 259 045 A3 



European Patent 
Office 



EUROPEAN SEARCH REPORT 



Application Number 

EP 02 25 2465 



DOCUMENTS CONSIDERED TO BE RELEVANT 



Category 



Citation of document with indication, where appropriate, 
of relevant passages 



Relevant 
to claim 



CLASSIFICATION OF THE 
APPLICATION (lnl.CI.7) 



SPINELLIS D ET AL: "Trusted third party 
services for deploying secure telemedical 
applications over the WWW" 
COMPUTERS & SECURITY. INTERNATIONAL 
JOURNAL DEVOTED TO THE STUDY OF TECHNICAL 
AND FINANCIAL ASPECTS OF COMPUTER 
SECURITY, ELSEVIER SCIENCE PUBLISHERS. 
AMSTERDAM, NL, 

vol. 18, no. 7, 1999, pages 627-639, 

XP004352742 

ISSN: 0167-4048 

* abstract * 

* page 632, left-hand column, line 1 - 
page 633, right-hand column, line 41 * 

* page 637, left-hand column, line 1 - 
page 638, left-hand column, line 28 * 

W00Y0UNG KIM ET AL: "A secure platform 
for peer-to-peer computing in the 
internet" 

PROCEEDINGS OF THE 35TH HAWAII 
INTERNATIONAL CONFERENCE ON SYSTEM 
SCIENCES, 

7 January 2001 (2001-01-07) , pages 
3980-3989, XP010587732 

* abstract * 

* page 3983, left-hand column, line 6 - 
page 3985, left-hand column, line 27 * 



1-18 



H04L29/06 



The present search report has been drawn up for all claims 



1-18 



TECHNICAL RELDS 
SEARCHED (lnt.CI.7) 



H04L 



Pace of search 

THE HAGUE 



Dale of completion of the search 

22 August 2003 



Examiner 

Adkhis, F 



CATEGORY OF CITED DOCUMENTS 

X ; particularly relevant rt taken alone 

Y : particularly relevant rf combined with another 

document of the same category 
A ' technological background 
O : non- written disclosure 
P : intermediate document 



T : theory or principle underlying the invention 
E : earlier patent document, but published on, or 

after the filing date 
D : daoument cited in the application 
L : document cited for other reasons 

& : member of the same patent fami!y, corresponding 
document 



2 



